<html>
<head><meta charset="utf-8"><title>Relaxing Limits on Pointer Sizes · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html">Relaxing Limits on Pointer Sizes</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="242298935"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242298935" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242298935">(Jun 11 2021 at 04:02)</a>:</h4>
<p>Currently in rust, several different clauses seem to imply limits on pointer sizes, and, in particular, whether or not they can have padding bits. These are:</p>
<ul>
<li>"The usize type is an unsigned integer type with the same number of bits as the platform's pointer type. It can represent every memory address in the process." - Rust Reference (<a href="https://doc.rust-lang.org/reference/types/numeric.html#machine-dependent-integer-types">https://doc.rust-lang.org/reference/types/numeric.html#machine-dependent-integer-types</a>)</li>
<li>" Rust does not support C platforms on which the C native integer type are not compatible with any of Rust's fixed-width integer type (e.g. <strong>because of padding-bits</strong>, lack of 2's complement, etc.)." - Note in Unsafe Code Guidelines (<a href="https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#layout-compatibility-with-c-native-integer-types">https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#layout-compatibility-with-c-native-integer-types</a>)</li>
<li>The fact that <code>usize as *mut () as usize</code> is safe rust code.</li>
</ul>
<p>This issue is discussed in &lt;<a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/255">https://github.com/rust-lang/unsafe-code-guidelines/issues/255</a>&gt;.</p>
<p>One issue I have for this: on the w65 platform, for the ABI I have designed, pointers necessarily have padding bits, due to the following reasons:</p>
<ol>
<li>The actual address size of the w65 is 24 bits if you consider the entire address space linearily (rather than 256 segments/banks of 64kiB), which was chosen for the ABI</li>
<li>Pointer values can be read by the CPU as a single (3-byte) unit</li>
<li>Single unit reads on the w65 sometimes wrap at bank bounderies, thus requiring alignment &gt;3 is required. Thus alignment 4 is necessary</li>
<li>Type alignment divides size, so thus the size of a pointer must be 4 bytes, with either 1 padding byte, or 8 padding bits (due to future extensions, it was chosen to treat them as padding bits that must be set to zero in the abi)</li>
</ol>
<p>The issue is that, by the above rules for integer types,  it seems like <code>usize</code> cannot have any padding bytes or padding bits, thus there is no way to satisfy that requirement with the current pointer ABI. </p>
<p>With that being said, I propose to relax/adopt the following rules:</p>
<ul>
<li>The width of pointer types shall be defined by the cfg-key <code>target_pointer_width</code>, which shall be the <em>implementation-defined</em> number of bits valid for use in a pointer value</li>
<li>If the pointer type width is 16, 32, 64, or 128, then the size and alignment of <code>usize</code>, <code>isize</code>, and any pointer to a <code>Sized</code> type shall be equivalent to the size and alignment of <code>u16</code>, <code>u32</code>, <code>u64</code>, or <code>u128</code>, respectively. </li>
<li>Otherwise, the size and alignment of all such types shall be the same <em>implementation-defined</em> value. Whether or not the types have any padding bits or padding bytes is <em>implementation-defined</em>, and the values of any such padding bits are unspecified. </li>
</ul>
<p>(These rules are based on the requirements for using u24-padded-to-u32 for pointers, and my interepretation of the most recent comment by <span class="user-mention" data-user-id="120791">@RalfJ</span> on the above linked UCG issue)</p>
<p>Would such a proposal be reasonable? <br>
One reason I bring this up now is that I intend to start work on a C Compiler that targets the aforementioned ABI at some point (likely to be a port of gcc), and I would like to ensure that the rules are as compatible as possible with rust's rules, but also ensure that the ABI rules are firmly in place for when I need to implement them in the C Compiler.</p>



<a name="242299369"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242299369" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242299369">(Jun 11 2021 at 04:11)</a>:</h4>
<p>On modern x86-64, pointers are only 48 bits, with the remainder of the bits being sign extended. However this is not exposed to users - compilers are supposed to pretend that pointers are 64 bits and only a small portion of the address space can actually be allocated. The type <code>usize</code> is 64 bits and so is <code>*mut ()</code>; it's just always an error to dereference a pointer outside 48 bits because that address space is unmapped, just like all other unmapped and unallocated memory. Why can't you do something like this for w65?</p>



<a name="242299578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242299578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242299578">(Jun 11 2021 at 04:16)</a>:</h4>
<p>The main potential ABI incompatibility with this approach is that this would allow passing <code>*mut ()</code> pointers into a function even if the high byte is not zero, provided that you don't use the pointer for dereferencing. It is not clear to me whether this is acceptable.</p>



<a name="242299699"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242299699" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242299699">(Jun 11 2021 at 04:19)</a>:</h4>
<p>for w65, is the C int 24 bits? I thought only size_t would be 24 bits.</p>



<a name="242304680"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242304680" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242304680">(Jun 11 2021 at 06:07)</a>:</h4>
<p>note that some new x86_64 processors also support 57-bit virtual addresses instead of only 48-bit: <a href="https://www.phoronix.com/scan.php?page=news_item&amp;px=Linux-5.5-5-Level-Paging">https://www.phoronix.com/scan.php?page=news_item&amp;px=Linux-5.5-5-Level-Paging</a></p>



<a name="242328960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242328960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242328960">(Jun 11 2021 at 10:52)</a>:</h4>
<blockquote>
<p>On modern x86-64, pointers are only 48 bits, with the remainder of the bits being sign extended. However this is not exposed to users - compilers are supposed to pretend that pointers are 64 bits and only a small portion of the address space can actually be allocated. The type <code>usize</code> is 64 bits and so is <code>*mut ()</code>; it's just always an error to dereference a pointer outside 48 bits because that address space is unmapped, just like all other unmapped and unallocated memory. Why can't you do something like this for w65?</p>
</blockquote>
<p>It's possible, though I think I considered this.  One issue, for the most part, accesses to such invalid addresses may be considered valid (and use the lower 24-bits of the address), as it wouldn't be possible for external hardware that performs memory mapping to trap such an accesses. While is also an issue, for, say, address 0 (specifically, for the use case I have, on the SNES, that address is outside of the control of the cartridge), and it's somewhat more obvious, imo, that 0usize as *mut u8 is not dereferenceable, then i32::MAX as *mut u8.</p>



<a name="242329202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242329202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242329202">(Jun 11 2021 at 10:55)</a>:</h4>
<blockquote>
<p>for w65, is the C int 24 bits? I thought only size_t would be 24 bits.</p>
</blockquote>
<p>int is 16 bits. I previously had it defined as 32 for consistency, but I decided to use the more efficient 16-bit type for that. size_t itself is also 16-bit, as is ptrdiff_t. Notably, this is another issue in that size_t is inconsistent with usize (and has totally different abi, size_t is passed in a register, usize is passed in a specially reserved memory location).</p>



<a name="242330288"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242330288" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242330288">(Jun 11 2021 at 11:09)</a>:</h4>
<p>Another reason the requirements for pointers exist was a legacy choice for the C++ abi, in that pointer-to-member functions where the same as pointer-to-functions, except that the high order bit (of the entire 32-bit value) was used to signal that the pointer was a vfn offset instead. I don't know how applicable that is any more, since the C++ abi was since replaced (but pmf might be a responsibility of the C abi). I eventually just decided to make all pointer types consistent, and allow room for software-level address space extensions in the future. This is slightly less of a concern with changing it, more of a rational for why it existed in the first place</p>



<a name="242341157"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242341157" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242341157">(Jun 11 2021 at 13:01)</a>:</h4>
<blockquote>
<p>One issue, for the most part, accesses to such invalid addresses may be considered valid (and use the lower 24-bits of the address), as it wouldn't be possible for external hardware that performs memory mapping to trap such an accesses.</p>
</blockquote>
<p>Accessing memory out of the bounds of an allocation is UB. It doesn't really matter that on this processor the addresses wrap around after 24 bits, the allocation itself lives in the first 2^24 bytes of the address space, so wraparound accesses are UB.</p>



<a name="242348135"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242348135" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242348135">(Jun 11 2021 at 13:55)</a>:</h4>
<p>True. I just find it potentially an issue, since it may appear to "just work". I know that some people will rely on undefined behaviour that "just works". Although, truncating in int-&gt;ptr casts could pose a similar issue.</p>



<a name="242356569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242356569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242356569">(Jun 11 2021 at 14:54)</a>:</h4>
<p>I don't know the intended definition of "padding" in the text you quoted. But I personally think "24 bit pointers stored in 32 bit words with 32-bit usize" would be entirely fine.</p>



<a name="242356755"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242356755" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242356755">(Jun 11 2021 at 14:56)</a>:</h4>
<p>That just results in a lot of invalid addresses, but that's perfectly acceptable; you can still round-trip any valid pointer.</p>



<a name="242362480"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242362480" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242362480">(Jun 11 2021 at 15:37)</a>:</h4>
<p>So the point I was making is that it's not 32-bit usize, it's only 24-bit <em>stored</em> as 32-bit. IIRC, Padding bytes are typically uninitialized in Rust and Rust may not distinguish them from padding bits, though in C, padding bits can be fixed to particular patterns, in this case, that pattern is all zeroes, and currently, this is a requirement of the ABI, at least at function call/return boundaries. </p>
<blockquote>
<ul>
<li>Pointer values are passed as 3 byte values, zero extended to 4 bytes. </li>
</ul>
</blockquote>
<p>As mentioned, the particular choice had several different motivations. I am at liberty to change it, if the current definition is unreasonable, though I would have to consider the implications for other language abis - in particular the Itanium C++ ABI (it seems like using the high bit is a reasonable choice for now, rather than disallow implementations from packing functions to use the low bit).</p>



<a name="242367206"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367206" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367206">(Jun 11 2021 at 16:11)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> Whether pointers can have a bit stolen from them to use for other purposes is a target-specific thing that target-specific code can use if it's careful; that isn't an issue with the target definition. Pointers and usize would still be 4 bytes, they just have a large invalid range.</p>



<a name="242367402"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367402" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367402">(Jun 11 2021 at 16:12)</a>:</h4>
<p>On Linux x86-64 targets, you can't have a valid pointer with the high bit set; target-specific code could rely on that if it wanted to.</p>



<a name="242367496"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367496" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367496">(Jun 11 2021 at 16:13)</a>:</h4>
<p>Invalid as in invalid to produce, or invalid to use? What I'm saying is that in the current text of the abi, it's the former.</p>



<a name="242367621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367621">(Jun 11 2021 at 16:14)</a>:</h4>
<p>The latter, but also it would be invalid to have one as a reference. But as a raw pointer it would be perfectly fine.</p>



<a name="242367878"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367878" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367878">(Jun 11 2021 at 16:16)</a>:</h4>
<p>If you want a different approach, I don't <em>think</em> we have any hard requirement that pointers be a power of two size, so you could make pointers and usize 3 bytes. :)</p>



<a name="242367950"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242367950" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242367950">(Jun 11 2021 at 16:16)</a>:</h4>
<p>(As long as 1-byte alignment is OK.)</p>



<a name="242368227"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242368227" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242368227">(Jun 11 2021 at 16:18)</a>:</h4>
<p>Ah, I just realized what you meant by a bank boundary; I had been thinking that that problem didn't need alignment to solve, but you can't actually prohibit pointers from spanning a bank boundary.</p>



<a name="242368362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242368362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242368362">(Jun 11 2021 at 16:19)</a>:</h4>
<p>OK, you do need 4-byte alignment and thus 4-byte size, then. You can still use 3-byte reads for anything that has to be a valid pointer (such as a reference). You would just need to use 4-byte operations for raw pointers.</p>



<a name="242368938"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242368938" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242368938">(Jun 11 2021 at 16:23)</a>:</h4>
<p>In response to your earlier proposal, I think that would break valid assumptions of portable Rust code. Concretely:</p>



<a name="242369061"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242369061" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242369061">(Jun 11 2021 at 16:24)</a>:</h4>
<ul>
<li>It's valid, in Rust, to store any arbitrary value in a raw pointer that fits in that raw pointer, as long as you never dereference it or put it in a reference type.</li>
</ul>



<a name="242369243"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242369243" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242369243">(Jun 11 2021 at 16:26)</a>:</h4>
<p>Yes, though 3/4-byte operations would typically be the same (the compiler <em>could</em> optimize by performing one read with m=1, thus an 8-bit read, then the other with m=0, 16-bits). The issue, is that, currently, the abi says pointers are 3 bytes, zero extended to 4, and I don't necessarily want to change it unless I absolutely have to, until I fully understand all of the implications (what it will or will not allow me to do in the future, what optimizations it disallows, effects on other, related abis, etc.). My proposal is intended to allow that definition, without being a significant burden.</p>



<a name="242369397"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242369397" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242369397">(Jun 11 2021 at 16:27)</a>:</h4>
<blockquote>
<ul>
<li>It's valid, in Rust, to store any arbitrary value in a raw pointer that fits in that raw pointer, as long as you never dereference it or put it in a reference type.</li>
</ul>
</blockquote>
<p>This is referring to the size of the actual value, correct? Technically, my proposal makes it valid to do that for the width of the pointer. If the pointer width is sane (16, 32, 64, and 128 explicitly mentioned), it also remains true.</p>



<a name="242369671"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242369671" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242369671">(Jun 11 2021 at 16:29)</a>:</h4>
<p>So, as far as I can tell, Rust's language requirements don't actually prohibit 3-byte pointers (with 3-byte usize), which that ABI would allow. It would, however, prevent 3-byte pointers with 4-byte alignment (because any type's size must be a multiple of its alignment) or 4-byte pointers where only 3 bytes are preserved.</p>



<a name="242369747"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242369747" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242369747">(Jun 11 2021 at 16:29)</a>:</h4>
<p>I'm wondering if there's <em>any</em> other way to solve the bank problem other than alignment.</p>



<a name="242370105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370105">(Jun 11 2021 at 16:31)</a>:</h4>
<p>Hang on, can you clarify something about the bank problem?</p>



<a name="242370133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370133">(Jun 11 2021 at 16:31)</a>:</h4>
<p>You said:</p>
<blockquote>
<p>Single unit reads on the w65 sometimes wrap at bank bounderies, thus requiring alignment &gt;3 is required. Thus alignment 4 is necessary</p>
</blockquote>



<a name="242370287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370287">(Jun 11 2021 at 16:32)</a>:</h4>
<p>Does that just mean that you can't do a 3-byte read that spans a bank boundary? Are bank boundaries at well-defined locations?</p>



<a name="242370318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370318">(Jun 11 2021 at 16:32)</a>:</h4>
<p>There are two I can think of:</p>
<ul>
<li>Copy pointer values (1 byte at a time, which is 3*6=18 cycles, plus the use) before using them, or</li>
<li>Disallow allocation of the last 3 bytes of a bank at the linker level.</li>
</ul>



<a name="242370358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370358">(Jun 11 2021 at 16:33)</a>:</h4>
<p>I can also think of some other alternatives.</p>



<a name="242370370"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370370" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370370">(Jun 11 2021 at 16:33)</a>:</h4>
<blockquote>
<p>Does that just mean that you can't do a 3-byte read that spans a bank boundary? Are bank boundaries at well-defined locations?</p>
</blockquote>
<p>Yes: modulo 64kiB</p>



<a name="242370551"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370551" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370551">(Jun 11 2021 at 16:34)</a>:</h4>
<p>You could define the ABI such that when you pass pointer values as parameters or return values, they're always passed on a 4-byte alignment. That wouldn't affect the general alignment of pointers, just the function call ABI (which can be defined arbitrarily). So, that would mean parameters and return values wouldn't require three 1-byte reads.</p>



<a name="242370608"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370608" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370608">(Jun 11 2021 at 16:35)</a>:</h4>
<p>Unfortunately that wouldn't solve things like arrays of pointers.</p>



<a name="242370735"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370735" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370735">(Jun 11 2021 at 16:36)</a>:</h4>
<p>But code generation for pointers could do something like "detect if you'd span a 64K boundary, use 3-byte read if not"; it wouldn't be the first target where there are efficient strategies that work for large numbers of things when amortized and not as well for single things.</p>



<a name="242370955"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242370955" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242370955">(Jun 11 2021 at 16:38)</a>:</h4>
<p>That sounds like potentially a lot of extra codegen. Even the extra code for the case could cause problems, as space is typically constrained (and functions also want to be allocated in one bank, since execution does <em>always</em> wrap).</p>



<a name="242371016"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371016" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371016">(Jun 11 2021 at 16:38)</a>:</h4>
<p><em>nod</em>. I don't actually think that'd be worth it for small numbers of pointers; it's more that you could do that to make large arrays of pointers more efficient.</p>



<a name="242371088"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371088" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371088">(Jun 11 2021 at 16:39)</a>:</h4>
<p>(Although, it would only apply to statics and dynamic allocation, which is currently defined to span 2 banks in some cases. Statics could be fixed by using link-time relaxation, maybe)</p>



<a name="242371192"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371192" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371192">(Jun 11 2021 at 16:40)</a>:</h4>
<p>If you avoided ever allowing objects to span banks, that would certainly make life easier.</p>



<a name="242371242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371242">(Jun 11 2021 at 16:41)</a>:</h4>
<p>Here's a completely different question: does the platform have a 4-byte read/write primitive?</p>



<a name="242371488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371488">(Jun 11 2021 at 16:42)</a>:</h4>
<p>No, only 2 and 1 byte. Pointers are special because of indirection, but they would be moved by some combination of 2 and 1 byte ops (Note, which one is used depends on the processor state, which is another reason to use 4-byte values, it's faster to do 2 2-byte loads, then 3 1-byte loads, by 5 cycles IIRC, plus size switch but if the processor is in 8-bit mode, it saves 1 cycle to do a 1-byte load, switch size, then a 2-byte load, then to switch first and do two loads)</p>



<a name="242371691"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371691" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371691">(Jun 11 2021 at 16:44)</a>:</h4>
<p>That was going to be my next question. If you store pointers in 4 bytes, can you just always load them via a pair of 2-byte reads? I'd assume that's still slower than using the specialized 3-byte pointer read, but faster than 4 1-byte reads?</p>



<a name="242371755"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371755" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371755">(Jun 11 2021 at 16:45)</a>:</h4>
<p>(Note that for Rust purposes this <em>only</em> applies to raw pointers; for references, because they're known-valid, you can always generate 3-byte reads and ignore one byte.)</p>



<a name="242371870"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242371870" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242371870">(Jun 11 2021 at 16:46)</a>:</h4>
<p>Well, yes, that's what they'd always be (again, modulo the optimization if m=1 first, which saves 2 cycles total, 1 load, 1 store)</p>



<a name="242372010"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372010" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372010">(Jun 11 2021 at 16:47)</a>:</h4>
<p>I'm confused; in the m=1 case, are you referring to the case of a known-valid pointer? Because it sounds like you're saying to load 1 byte, then 2 bytes, which would only load a total of 3 bytes.</p>



<a name="242372327"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372327" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372327">(Jun 11 2021 at 16:50)</a>:</h4>
<p>Wait, does the processor actually have a 3-byte load primitive for pointers, or does it just have 2-byte and 1-byte loads in general (and "3-byte" was your description of the optimized algorithm that can take advantage of starting in 1-byte mode to just skip the first byte)?</p>



<a name="242372521"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372521" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372521">(Jun 11 2021 at 16:51)</a>:</h4>
<p>Sort of the latter, but for indirections, it does read the whole pointer value (assuming indirect-long addressing mode). Actually copying pointer values has to be done using 2 and 1 byte operations.</p>



<a name="242372821"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372821" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372821">(Jun 11 2021 at 16:53)</a>:</h4>
<p>I see. So, there's a "read 3 bytes from this indirect memory address" mechanism, but not a more efficient "read 3 bytes from this direct memory address" mechanism, and using indirect for direct is still more expensive than doing a 2-byte operation?</p>



<a name="242372916"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372916" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372916">(Jun 11 2021 at 16:54)</a>:</h4>
<p>By Indirection here I mean actually indirecting to the pointer.</p>



<a name="242372930"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242372930" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242372930">(Jun 11 2021 at 16:54)</a>:</h4>
<p>(Or calling a function pointer)</p>



<a name="242373060"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373060" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373060">(Jun 11 2021 at 16:55)</a>:</h4>
<p>For the indirect-long and indirect-long-direct addressing modes, the CPU reads a 24-bit value form the immediate address (possibly within the direct page), then performs the memory access on <em>that</em> location.</p>



<a name="242373116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373116">(Jun 11 2021 at 16:56)</a>:</h4>
<p>Ah, I see.</p>



<a name="242373182"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373182" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373182">(Jun 11 2021 at 16:56)</a>:</h4>
<p>So dereferencing is reasonably efficient, and it's just that reading and writing needs to use 2-byte or 1-byte reads.</p>



<a name="242373319"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373319" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373319">(Jun 11 2021 at 16:57)</a>:</h4>
<p>Yeah. Welcome to the 65C816, and the mess it inherited and extended from the CMOS 6502.</p>



<a name="242373382"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373382" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373382">(Jun 11 2021 at 16:58)</a>:</h4>
<p>Doesn't seem <em>that</em> different from the 8086/80286 with its 24-byte far pointers and segmentation.</p>



<a name="242373623"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373623" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373623">(Jun 11 2021 at 16:59)</a>:</h4>
<p>I guess that's true, and you could argue that "banks" are forms of segments, and that would be a valid choice. I chose to make use of the address space as a whole, and defined it to be a single linear memory space (and then did my best to ensure that it's weird "quirks" didn't cause bad things to happen).</p>



<a name="242373725"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373725" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373725">(Jun 11 2021 at 17:00)</a>:</h4>
<p>I think that's entirely valid, and I wasn't suggesting actually using segmentation; it's more that I was relating the underlying hardware to what I'm familiar with. :)</p>



<a name="242373776"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373776" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373776">(Jun 11 2021 at 17:00)</a>:</h4>
<p>I think your approach of making it feel like a flat linear space as much as possible is likely to make the Rust target for the platform more accessible.</p>



<a name="242373781"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373781" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373781">(Jun 11 2021 at 17:00)</a>:</h4>
<p>In any case, so the answer is that it would be too unreasonable to accommodate padding bits in a pointer type for rust support, then?</p>



<a name="242373941"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242373941" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242373941">(Jun 11 2021 at 17:01)</a>:</h4>
<p>Yes, for the concrete version that it would invalidate otherwise-portable assumptions valid in unsafe Rust code. However, I do have some thoughts on what you might be able to do to preserve efficiency on the platform as much as possible.</p>



<a name="242374213"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374213" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374213">(Jun 11 2021 at 17:03)</a>:</h4>
<p>I definately don't want to go down the rabbit hole of not making pointers 4-byte aligned, at least not today, so I can probably make it use the whole four bytes, but I'd have to be fairly careful, especially with future extensions.</p>



<a name="242374335"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374335" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374335">(Jun 11 2021 at 17:04)</a>:</h4>
<p>One question, though. You said references are known valid. What about &amp;()?</p>



<a name="242374705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374705">(Jun 11 2021 at 17:07)</a>:</h4>
<p>AFAIK any address, other than 0, is valid for size 0 align 1. Wouldn't that make (0xff000000u32 as *const ()) also valid? In that case, the optimization wouldn't be applicable to pointers to ZSTs.</p>



<a name="242374707"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374707" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374707">(Jun 11 2021 at 17:07)</a>:</h4>
<p><code>&amp;()</code> is still not allowed to for example be a null pointer. In addition for ZST's with an alignment bigger than 1 byte references need to be aligned too.</p>



<a name="242374770"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374770" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374770">(Jun 11 2021 at 17:07)</a>:</h4>
<p>Given the additional detail that the platform doesn't actually have a 3-byte read primitive (just the ability to dereference 3-byte pointers), I think the approach of 4-byte pointers with 4-byte alignment makes the most sense, yeah. You'd could use a pair of 2-byte reads to copy them when you have a raw pointer, and for references you can use the optimization of knowing only 3 bytes are valid. Code that works with references will be as efficient as possible, and should be possible to optimize down to the code you might write in the first place. Code that works with raw pointers will be somewhat less efficient, <em>but</em>, your C compiler could absolutely have an optimization to make it possible to declare a pointer as "known valid" (via a combination of things like GCC's <code>__attribute__((nonnull))</code> and detecting things like "you dereference this so it must be valid"), and you could translate such pointers in C to references in Rust.</p>



<a name="242374897"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242374897" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242374897">(Jun 11 2021 at 17:08)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> <code>0xff000000u32 as *const ()</code> is valid Rust, but you'd get UB if you turned that into a reference or dereferenced it.</p>



<a name="242375303"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375303" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375303">(Jun 11 2021 at 17:12)</a>:</h4>
<p>I don't just want to say "here's how you can make Rust code efficient" and stop at that, because I also care about the C ABI and C/Rust interoperability, and I don't want Rust's requirements to be the cause of C inefficiency. But, for instance, you could define as part of your ABI a distinction between "known-valid" pointers and "not known to be valid" pointers, and pass around <code>&amp;T</code> as the former and <code>*T</code> as the latter.</p>



<a name="242375318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375318">(Jun 11 2021 at 17:12)</a>:</h4>
<p>Interestingly, Miri currently does not agree, or at least, does not trap: <a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e1930120d5c624ddce331aeb9bfbf438">https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e1930120d5c624ddce331aeb9bfbf438</a></p>



<a name="242375358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375358">(Jun 11 2021 at 17:12)</a>:</h4>
<p>Might take some fiddling in Rust to make the <code>extern "C"</code> ABI understand that pointers and references have a different calling convention, but it seems potentially feasible.</p>



<a name="242375448"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375448" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375448">(Jun 11 2021 at 17:13)</a>:</h4>
<p>Does that seem vaguely plausible?</p>



<a name="242375885"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375885" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375885">(Jun 11 2021 at 17:17)</a>:</h4>
<p>In short, I think it would break too much to allow for padding in pointer or usize types in Rust, but I <em>do</em> think there are ways we could improve the language/compiler to still provide efficiency for your target.</p>



<a name="242375888"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242375888" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242375888">(Jun 11 2021 at 17:17)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242375358">said</a>:</p>
<blockquote>
<p>Might take some fiddling in Rust to make the <code>extern "C"</code> ABI understand that pointers and references have a different calling convention, but it seems potentially feasible.</p>
</blockquote>
<p>That sort of seems to me like a much larger breaking change, because there is actual stable documentation saying references and pointers have the same abi. It also seems like it would just be potential optimization that can be done on the caller side, that I wouldn't think would necessarily need any sort of special support at the ABI level.</p>



<a name="242376001"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376001" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376001">(Jun 11 2021 at 17:18)</a>:</h4>
<p>It can't <em>just</em> be done on the caller or callee side, because they might not know what the other side expects otherwise.</p>



<a name="242376046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376046">(Jun 11 2021 at 17:18)</a>:</h4>
<p>It <em>would</em> be valid, as an optimization, for a callee to just load 3 bytes if knows it's going to receive and use a valid pointer.</p>



<a name="242376091"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376091" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376091">(Jun 11 2021 at 17:19)</a>:</h4>
<p>But the caller of that function wouldn't necessarily know that, and would have to store 4 bytes if the function is declared to take a raw pointer.</p>



<a name="242376158"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376158" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376158">(Jun 11 2021 at 17:19)</a>:</h4>
<p>I'm trying to think of how to make <code>extern "C" fn c_func(param: &amp;MyStruct)</code> more efficient.</p>



<a name="242376183"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376183" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376183">(Jun 11 2021 at 17:20)</a>:</h4>
<p>Yes indeed. Likewise, if the caller knows it's passing a valid pointer it can just copy 4 bytes.</p>



<a name="242376274"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376274" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376274">(Jun 11 2021 at 17:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242376183">said</a>:</p>
<blockquote>
<p>Yes indeed. Likewise, if the caller knows it's passing a valid pointer it can just copy 4 bytes.</p>
</blockquote>
<p>I assume you mean 3 bytes here? :)</p>



<a name="242376294"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376294" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376294">(Jun 11 2021 at 17:20)</a>:</h4>
<p>Yeah.</p>



<a name="242376324"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376324" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376324">(Jun 11 2021 at 17:20)</a>:</h4>
<p>And yeah, if you're <em>passing</em> a reference you can just copy 3 bytes, though you have to make sure the stack slot you're using has a zeroed 4th byte.</p>



<a name="242376407"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376407" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376407">(Jun 11 2021 at 17:21)</a>:</h4>
<p>Yes (stack slot, or memory location, since 4-byte values get a few reserved memory locations).</p>



<a name="242376415"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376415" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376415">(Jun 11 2021 at 17:21)</a>:</h4>
<p>As an aside, at a minimum, if you do cross-language LTO, the optimizer could track things like "this function accepts a valid pointer and it's being called with a valid pointer so pass it as 3 bytes".</p>



<a name="242376569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376569">(Jun 11 2021 at 17:22)</a>:</h4>
<p>And I think for a very memory-constrained target like this, cross-language LTO would have a lot of benefits.</p>



<a name="242376650"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242376650" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242376650">(Jun 11 2021 at 17:23)</a>:</h4>
<p>Certainly.</p>



<a name="242377105"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242377105" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242377105">(Jun 11 2021 at 17:27)</a>:</h4>
<p>I hope that this constraint isn't too onerous for the ABI. I absolutely think it's a tradeoff between consistent/robust unsafe code and maximum possible optimization.</p>



<a name="242377856"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242377856" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242377856">(Jun 11 2021 at 17:32)</a>:</h4>
<p>It potentially has implications for future extensions involving synthetic extensions to the address space. However it likely won't be a significant issue on that front. The only potential issue I see is, one could do something like this (in rust or otherwise) to synthesize a C++ pmvf:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[repr(C)]</span><span class="w"></span>
<span class="k">pub</span><span class="w"> </span><span class="k">struct</span> <span class="nc">ItaniumPMF</span><span class="p">(</span><span class="o">*</span><span class="k">mut</span><span class="w"> </span><span class="p">(),</span><span class="w"> </span><span class="kt">usize</span><span class="p">);</span><span class="w"></span>
<span class="n">ItaniumPMF</span><span class="p">(</span><span class="mh">0x80000000</span><span class="w"> </span><span class="k">as</span><span class="w"> </span><span class="o">*</span><span class="k">mut</span><span class="w"> </span><span class="p">(),</span><span class="w"> </span><span class="mi">0</span><span class="p">)</span><span class="w"></span>
</code></pre></div>
<p>However, it also seems like something one couldn't do by accident.</p>



<a name="242377983"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242377983" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242377983">(Jun 11 2021 at 17:33)</a>:</h4>
<p>(Would also require knowledge of vtable offsets, but those are well defined in this case)</p>



<a name="242378107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378107">(Jun 11 2021 at 17:34)</a>:</h4>
<p>Dereferencing something like that would be invoking UB, and "this gets treated as a pmvf" would just be the specific variety of nasal demon invoked. ;)</p>



<a name="242378646"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378646" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378646">(Jun 11 2021 at 17:38)</a>:</h4>
<p>Also, when you mention "future extensions involving synthetic extensions to the address space", that's <em>definitely</em> something you should decide very clearly in advance and document. If people see unused bits, especially on a "constrained and creativity-inspiring" target like the SNES, they may make use of those bits, in which case you'd be stuck potentially breaking their code with future synthetic extensions, or arranging to let people opt in and out. If you want to be able to use those bits yourself as part of the target in the future, you may want to reserve them now.</p>



<a name="242378718"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378718" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378718">(Jun 11 2021 at 17:38)</a>:</h4>
<p>x86 had some bad experiences with "reserved but not really reserved" bits, where once popular systems started using them they couldn't actually be reclaimed.</p>



<a name="242378761"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378761" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378761">(Jun 11 2021 at 17:39)</a>:</h4>
<p>Indeed <em>stares at jscore</em></p>



<a name="242378939"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378939" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378939">(Jun 11 2021 at 17:40)</a>:</h4>
<p>Technically, they were reserved until ~20 minutes ago. For actual dereferencing, they still are.</p>



<a name="242378959"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378959" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378959">(Jun 11 2021 at 17:40)</a>:</h4>
<p>Oh, absolutely.</p>



<a name="242378993"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242378993" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242378993">(Jun 11 2021 at 17:41)</a>:</h4>
<p>It'd be UB to dereference a pointer with a non-zero high byte.</p>



<a name="242379006"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379006" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379006">(Jun 11 2021 at 17:41)</a>:</h4>
<p>And you could choose to define that behavior later.</p>



<a name="242379027"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379027" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379027">(Jun 11 2021 at 17:41)</a>:</h4>
<p>It's more a question of whether people think they can, for instance, use the high byte as a type code for an interpreter. :)</p>



<a name="242379053"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379053" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379053">(Jun 11 2021 at 17:41)</a>:</h4>
<p>Or as their own creative bank-switch extension mechanism.</p>



<a name="242379087"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379087" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379087">(Jun 11 2021 at 17:41)</a>:</h4>
<p>I personally would <em>suggest</em> that you document those bits as not used by valid pointers, <em>but</em> that future target extensions might use them, so any code making use of them as reserved bits should know that they might have to redesign their system in the face of future target extensions.</p>



<a name="242379183"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379183" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379183">(Jun 11 2021 at 17:42)</a>:</h4>
<p>That seems like the right balance of letting people be creative but also warning them that you also might want to provide creativity at the target level later.</p>



<a name="242379216"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379216" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379216">(Jun 11 2021 at 17:42)</a>:</h4>
<p>It'd be fun to use those for addressing extension chips, for instance. Or having a target-level bank swap mechanism. :)</p>



<a name="242379915"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242379915" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242379915">(Jun 11 2021 at 17:48)</a>:</h4>
<p>FWIW, I'm excited about being able to use Rust on the SNES. Thank you for working on it.</p>



<a name="242380164"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242380164" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242380164">(Jun 11 2021 at 17:50)</a>:</h4>
<p>Indeed. It's a ways off, though assuming all goes well with binutils and gcc, it may not be so far away (rustc_codegen_gcc and gcc-rs).</p>



<a name="242380267"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242380267" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242380267">(Jun 11 2021 at 17:51)</a>:</h4>
<p>Does gcc already have an SNES target, or is that something you're looking to add?</p>



<a name="242381741"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242381741" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242381741">(Jun 11 2021 at 18:03)</a>:</h4>
<p>Something I'm looking to add. I'm already about 80% done with GNU binutils, though I have a <em>few</em> bugs to work out, and gdb is doing something. gcc is a logical next step (I tried llvm, but llvm really likes to assume things... Like the fact that instructions <em>don't</em> change size in the middle of a function)</p>



<a name="242382417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242382417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242382417">(Jun 11 2021 at 18:07)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242381741">said</a>:</p>
<blockquote>
<p>Something I'm looking to add. I'm already about 80% done with GNU binutils, though I have a <em>few</em> bugs to work out, and gdb is doing something. gcc is a logical next step (I tried llvm, but llvm really likes to assume things... Like the fact that instructions <em>don't</em> change size in the middle of a function)</p>
</blockquote>
<p>Can you elaborate on the instruction size changes? x86 instructions are also variable-sized.</p>



<a name="242382452"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242382452" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242382452">(Jun 11 2021 at 18:08)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242381741">said</a>:</p>
<blockquote>
<p>(I tried llvm, but llvm really likes to assume things... Like the fact that instructions <em>don't</em> change size in the middle of a function)</p>
</blockquote>
<p>Heh. Sticks out like a sore THUMB? ;)</p>



<a name="242382626"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242382626" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242382626">(Jun 11 2021 at 18:09)</a>:</h4>
<p>I'm guessing the size change is less of an issue than a mode change?</p>



<a name="242382808"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242382808" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242382808">(Jun 11 2021 at 18:10)</a>:</h4>
<p>adc imm is an example<br>
Say, <code>adc 1</code>. If  <code>m=0</code> in the processor status word, this is encoded as 3 bytes [c9 01 00], but if <code>m=1</code> (or the less common case of <code>e=1</code>, which is 6502 emulation mode) it's encoded as two bytes <code>[c9 01]</code>.</p>



<a name="242383014"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242383014" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242383014">(Jun 11 2021 at 18:12)</a>:</h4>
<p>The only difference between the two, is one has an extra trailing byte. Which means that the size of a few instructions varies between changes in the <code>m</code> or also the <code>x</code> flag (which affects the size of the X and Y registers, and operations involving them). LLVM really does not appreciate this fact.</p>



<a name="242383094"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242383094" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242383094">(Jun 11 2021 at 18:12)</a>:</h4>
<p>It seems like treating the processor as having variable-length instructions would solve <em>part</em> of that. But I'm guessing that LLVM really doesn't like having to emit instructions in a stateful fashion that depends on the mode bit.</p>



<a name="242383744"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242383744" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242383744">(Jun 11 2021 at 18:18)</a>:</h4>
<blockquote>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242381741">said</a>:</p>
</blockquote>
<blockquote>
<p>Something I'm looking to add. I'm already about 80% done with GNU binutils, though I have a <em>few</em> bugs to work out, and gdb is doing something. gcc is a logical next step (I tried llvm, but llvm really likes to assume things... Like the fact that instructions <em>don't</em> change size in the middle of a function)</p>
</blockquote>
<blockquote>
<p>Can you elaborate on the instruction size changes? x86 instructions are also variable-sized.</p>
</blockquote>
<p>In the case of x86, instructions don't change size without a mode change, which in all cases I know of, requires a far jmp (idk about virtual 8086 mode, though).</p>



<a name="242383897"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242383897" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242383897">(Jun 11 2021 at 18:19)</a>:</h4>
<p>What's the mechanism for a mode change in the 65c816?</p>



<a name="242384256"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242384256" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242384256">(Jun 11 2021 at 18:22)</a>:</h4>
<p>For size flags, the rep and sep instructions. For emulation mode, sec (set carry) or clc (clear carry) followed by xce, though this is easier to treat as an actual mode change. One issue is that it's necessary to set m=1 or x=1 to perform 1 byte memory operations.</p>



<a name="242386257"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242386257" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242386257">(Jun 11 2021 at 18:37)</a>:</h4>
<p>maybe treat the mode bit as another separate register and treat the two different instruction sizes as two different instructions in llvm and have all mode-dependent instructions have another constant argument that is allocated to the mode register?</p>



<a name="242386488"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242386488" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242386488">(Jun 11 2021 at 18:39)</a>:</h4>
<p>see also how llvm handles fixed-size vectors on risc-v v, which is similar in that they require the VL to be a particular value and if it's not that value the instruction does unexpected stuff (kinda UB)</p>



<a name="242387711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242387711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242387711">(Jun 11 2021 at 18:49)</a>:</h4>
<p>Possibly. In any case, my priorities are gcc, and also lccc, though the latter is much further away. If I could get llvm to work, that would be nice, but it's less of a priority (especially with rustc_codegen_gcc, and gcc-rs)</p>



<a name="242388013"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242388013" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242388013">(Jun 11 2021 at 18:51)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242348135">said</a>:</p>
<blockquote>
<p>True. I just find it potentially an issue, since it may appear to "just work". I know that some people will rely on undefined behaviour that "just works". Although, truncating in int-&gt;ptr casts could pose a similar issue.</p>
</blockquote>
<p>If it's UB, we could always emit range checks in debug mode as part of dereferencing that abort, to help make it more obvious that it's bad.  But in general, it's completely normal for "bad" pointer dereferences to sometimes work find.</p>



<a name="242389114"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242389114" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242389114">(Jun 11 2021 at 19:00)</a>:</h4>
<p>a good example is on WebAssembly, where dereferencing a null pointer works fine, but is still llvm-level UB</p>



<a name="242389844"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242389844" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242389844">(Jun 11 2021 at 19:06)</a>:</h4>
<p><span class="user-mention silent" data-user-id="125270">scottmcm</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242388013">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242348135">said</a>:</p>
<blockquote>
<p>True. I just find it potentially an issue, since it may appear to "just work". I know that some people will rely on undefined behaviour that "just works". Although, truncating in int-&gt;ptr casts could pose a similar issue.</p>
</blockquote>
<p>If it's UB, we could always emit range checks in debug mode as part of dereferencing that abort, to help make it more obvious that it's bad.  But in general, it's completely normal for "bad" pointer dereferences to sometimes work find.</p>
</blockquote>
<p>In general, at least on modern hosted platforms, you'd either trap, break something, or the compiler helpfully elides your code. I guess this is less true on embedded, though. I would think the third point would be somewhat less common, so there may be potential for someone to abuse it to access address <code>0</code> (side note, rust requiring nullptr to be the zero address is slightly annoying, but not dealbreaking; if I have something that gets allocated at address 0, I have bigger problems, like the stack is about to wrap into ROM, then it's technically unsound to use that object)</p>



<a name="242392802"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242392802" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242392802">(Jun 11 2021 at 19:33)</a>:</h4>
<blockquote>
<p>I would think the third point would be somewhat less common</p>
</blockquote>
<p>I think in the linux kernel they had issues with null checks being elided due to null derefs happening before the check so the compiler exploited some "this obviously can't be null" UB</p>



<a name="242393042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393042">(Jun 11 2021 at 19:35)</a>:</h4>
<p>BTW, for supporting w65 in general, the last time this was raised, IIRC <span class="user-mention" data-user-id="239881">@Josh Triplett</span> mentioned it may be a good idea for T-lang to "approve" targets individually, rather than allowing implementations to just add support for new targets (though I do not know how official that statement was). If this is the case, what would be the proper process for that. Would it do as just a rust-lang/lang-team or rust-lang/rust issue, or would it need something larger, such as an MCP or RFC?</p>



<a name="242393151"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393151" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393151">(Jun 11 2021 at 19:36)</a>:</h4>
<p><span class="user-mention silent" data-user-id="330154">The 8472</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242392802">said</a>:</p>
<blockquote>
<blockquote>
<p>I would think the third point would be somewhat less common</p>
</blockquote>
<p>I think in the linux kernel they had issues with null checks being elided due to null derefs happening before the check so the compiler exploited some "this obviously can't be null" UB</p>
</blockquote>
<p>I was specifically referring to <code>&gt;0xffffff</code> addresses. I am very much aware that compilers love to delete null pointer checks, I  happen to like that myself.</p>



<a name="242393371"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393371" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393371">(Jun 11 2021 at 19:38)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> I think it would take a compiler MCP. There isn't an established process for such approvals, and I suspect we will want to establish one if we're going to do many of these; I think one helpful piece of information would be what subset of the tier three requirements you'd expect to be able to meet, and what set would be onerous to meet.</p>



<a name="242393427"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393427" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393427">(Jun 11 2021 at 19:39)</a>:</h4>
<p>ah. if you give it range constraints then it'll still miscompile that.</p>



<a name="242393428"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393428" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393428">(Jun 11 2021 at 19:39)</a>:</h4>
<p>That would give a rough idea of what the "tier 4" (design approved but not in tree) requirements would be.</p>



<a name="242393901"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242393901" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242393901">(Jun 11 2021 at 19:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242393371">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> I think it would take a compiler MCP. There isn't an established process for such approvals, and I suspect we will want to establish one if we're going to do many of these; I think one helpful piece of information would be what subset of the tier three requirements you'd expect to be able to meet, and what set would be onerous to meet.</p>
</blockquote>
<p>Ah. One thing it would do is it would want to add <code>asm!</code> support, as well as a single function abi, <code>extern"w65-interrupt"</code> (for which the behaviour is described in the ABI, but it's used for defining native-mode interrupt handlers). </p>
<p>Otherwise, I'll look into the tier 3 requirements, and see what will and will not work.</p>



<a name="242394270"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242394270" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242394270">(Jun 11 2021 at 19:47)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242393428">said</a>:</p>
<blockquote>
<p>That would give a rough idea of what the "tier 4" (design approved but not in tree) requirements would be.</p>
</blockquote>
<p>i wonder if it would be worth having a repository for these, since otherwise it feels like it might just get lost. and also, the process for additions could plausibly be PRs into that repository (with suitable amounts of discussion)</p>



<a name="242394509"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242394509" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242394509">(Jun 11 2021 at 19:48)</a>:</h4>
<p>it seems wroth figuring out since rustc_codegen_gcc/gcc-rs will enable a bunch of new targets — although maybe in the first case i guess those would plausibly live as tier 3 in the r-l/r repo</p>



<a name="242423243"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242423243" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242423243">(Jun 12 2021 at 03:06)</a>:</h4>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242394509">said</a>:</p>
<blockquote>
<p>it seems wroth figuring out since rustc_codegen_gcc/gcc-rs will enable a bunch of new targets — although maybe in the first case i guess those would plausibly live as tier 3 in the r-l/r repo</p>
</blockquote>
<p>Yeah, I'd expect all the <code>rustc_codegen_gcc</code> targets to live in rust-lang/rust. I'm hoping that will serve to enable all the requisite targets, but we may need to add a tier-4 review process for targets if people end up wanting to add some via gcc-rs.</p>



<a name="242441017"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242441017" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242441017">(Jun 12 2021 at 09:58)</a>:</h4>
<p>Due to <a href="https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.CodegenBackend.html#method.target_override"><code>CodegenBackend::target_override</code></a> it is not strictly necessary for cg_gcc targets to live in rust-lang/rust as it allows a backend to specify an arbitrary target specification without requiring the user to pass a json file to rustc.</p>



<a name="242454550"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242454550" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242454550">(Jun 12 2021 at 14:50)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242375318">said</a>:</p>
<blockquote>
<p>Interestingly, Miri currently does not agree, or at least, does not trap: <a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e1930120d5c624ddce331aeb9bfbf438">https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2018&amp;gist=e1930120d5c624ddce331aeb9bfbf438</a></p>
</blockquote>
<p>zero-sized accesses are special. they are okay at any sufficiently aligned integer address except 0.<br>
if this was UB, there's be a lot of UB in the standard library...</p>



<a name="242454633"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242454633" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242454633">(Jun 12 2021 at 14:52)</a>:</h4>
<p>Regarding the original question -- I am not at all an expert on these low-level matters, but I don't like the idea of an integer type with padding. That just opens too many thorny questions...</p>



<a name="242454714"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242454714" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242454714">(Jun 12 2021 at 14:54)</a>:</h4>
<p>My personal preference would be 32bit pointers where accessing anything &gt;= 2^24 is UB. that seems like the cleanest approach to me. it would be almost equivalent to what you propose, I think, except that <code>wrapping_offset</code> would wrap around at 32bit instead of 24bit. but I am certainly not enough of an expert to see all the consequences of this.<br>
Rust has tons of UB that "happens to work", so I think that is a problem best solved by docs, teaching, tools like Miri, ...</p>



<a name="242476373"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242476373" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242476373">(Jun 12 2021 at 22:42)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242454714">said</a>:</p>
<blockquote>
<p>My personal preference would be 32bit pointers where accessing anything &gt;= 2^24 is UB. that seems like the cleanest approach to me. it would be almost equivalent to what you propose, I think, except that <code>wrapping_offset</code> would wrap around at 32bit instead of 24bit. but I am certainly not enough of an expert to see all the consequences of this.<br>
Rust has tons of UB that "happens to work", so I think that is a problem best solved by docs, teaching, tools like Miri, ...</p>
</blockquote>
<p>Based on the previous discussion this is basically what I ended up using (and I modified  the ABI to not violate those requirements. <br>
As for the particular case, inventing pointers is a common practice in embedded software, so you wouldn't be able to check you aren't inventing any incorrect pointers with miri, since I'd assume that miri (if it even ever can be used with a w65 target) would reject dereferencing any magic pointers.  Docs would help, for sure, but it's not going to elimitate people doing it by accident, and there is limited ability for runtime diagnostics on actual hardware/emulators in the out-of-range case. Though to be fair, a lot of cases would likely had such  limited ability.</p>



<a name="242498598"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242498598" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242498598">(Jun 13 2021 at 08:39)</a>:</h4>
<blockquote>
<p>inventing pointers is a common practice in embedded software, so you wouldn't be able to check you aren't inventing any incorrect pointers with miri, since I'd assume that miri (if it even ever can be used with a w65 target) would reject dereferencing any magic pointers</p>
</blockquote>
<p>well, Miri could have support for plugins where you can define the "well-known" memory ranges that exist at fixed addresses, and let the interpreted program access them :D</p>



<a name="242498646"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242498646" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242498646">(Jun 13 2021 at 08:40)</a>:</h4>
<p>Miri should be able to interpret all targets that rustc supports, though I dont think <code>no_std</code> targets were ever tested</p>



<a name="242544683"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242544683" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242544683">(Jun 14 2021 at 02:31)</a>:</h4>
<p>Ralf any time you want to make miri support GBA programs just send me a ping and i'll answer any memory range questions you got ;3</p>



<a name="242545101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242545101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242545101">(Jun 14 2021 at 02:42)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242498598">said</a>:</p>
<blockquote>
<blockquote>
<p>inventing pointers is a common practice in embedded software, so you wouldn't be able to check you aren't inventing any incorrect pointers with miri, since I'd assume that miri (if it even ever can be used with a w65 target) would reject dereferencing any magic pointers</p>
</blockquote>
<p>well, Miri could have support for plugins where you can define the "well-known" memory ranges that exist at fixed addresses, and let the interpreted program access them :D</p>
</blockquote>
<p>I suppose that would work. Though, would it also be doable the same way for extern symbols, which, imo, is the correct way to do magic addresses?</p>



<a name="242589233"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242589233" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242589233">(Jun 14 2021 at 12:33)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242544683">said</a>:</p>
<blockquote>
<p>Ralf any time you want to make miri support GBA programs just send me a ping and i'll answer any memory range questions you got ;3</p>
</blockquote>
<p>I don't think I'll implement that. ;) but I'd be happy to help others that want to get this implemented^^</p>



<a name="242589324"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242589324" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242589324">(Jun 14 2021 at 12:34)</a>:</h4>
<blockquote>
<p>I suppose that would work. Though, would it also be doable the same way for extern symbols, which, imo, is the correct way to do magic addresses?</p>
</blockquote>
<p>that's the same thing, IMO, plus an extra table mapping extern symbol names to addresses (which likely will then be in one of these hard-coded "well-known" memory ranges)</p>



<a name="242678848"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242678848" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242678848">(Jun 15 2021 at 01:38)</a>:</h4>
<p>I would also like to raise another potential issue I just realised. From the documents I linked, Rust seems to require that the size and <em>alignment</em> of <code>*{const,mut} T</code> be equal to <code>usize</code>. However, all of the integer types in the current ABI have Alignment requirement 2. Could this limit be relaxed, or is there also potential for issues with that? This is a slightly lesser issue, but due to space constraints (due to tthe fact alignment is inherited), I would prefer not raising max fundamental alignment to 4 when it neither poses a potential access issue nor penalizes codegen in any way, and I do not know whether gcc in particular is capable of directly representing an integer type with an extended alignment requirement.</p>



<a name="242678888"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242678888" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242678888">(Jun 15 2021 at 01:40)</a>:</h4>
<p>I don't see any fundamental reason why the alignment needs to be <em>equal</em>. It needs to <em>divide</em> the size evenly.</p>



<a name="242679455"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242679455" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242679455">(Jun 15 2021 at 01:52)</a>:</h4>
<p>It's currently equal for pointers. If <code>usize</code> is, in fact, required to have the same size and alignment requirement as pointers, then the result is that the size equals the alignment for <code>usize</code> (which would currently give it the largest fundamental alignment, greater than the alignment of other integers).</p>



<a name="242764719"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242764719" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242764719">(Jun 15 2021 at 16:58)</a>:</h4>
<p><span class="user-mention" data-user-id="257758">@Connor Horman</span> So, I do expect that <code>usize</code> and pointers need to have the same size and alignment requirements. However, I don't see any fundamental reason their alignment <em>needs</em> to be equal to their size, if your target doesn't require that.</p>



<a name="242764814"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242764814" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242764814">(Jun 15 2021 at 16:58)</a>:</h4>
<p>That said, don't you need alignment 4 because of the bank-spanning problem?</p>



<a name="242764847"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242764847" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242764847">(Jun 15 2021 at 16:58)</a>:</h4>
<p>Alignment 2 would allow pointers to span banks.</p>



<a name="242766327"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242766327" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242766327">(Jun 15 2021 at 17:09)</a>:</h4>
<p>Yes, pointers need to be alignment 4 because of that issue.<br>
 However, currently none of the integer types (or non-pointer fundamental types, for that matter) have alignment &gt;2, and I don't necessarily want to assign an alignment requirement greater than is required or useful (so if <code>usize</code> gets alignment 4, then  either I also make <code>u32</code>, <code>u64</code>, and <code>u128</code> alignment 4, or <code>usize</code> has greater alignment than any other type). That's the issue here. <br>
I believe neither C nor C++ require that <code>uintptr_t</code> and <code>intptr_t</code> have the same alignment requirement as <code>void*</code>.</p>



<a name="242774390"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242774390" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242774390">(Jun 15 2021 at 18:04)</a>:</h4>
<p>I suppose that as long as usize has an alignment requirement no <em>more</em> than a pointer, you can always round-trip. It would just mean that not every valid usize is a valid pointer.</p>



<a name="242775263"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242775263" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242775263">(Jun 15 2021 at 18:10)</a>:</h4>
<p>Wouldn't that only apply to ptr/reference casts (which brings to mind things like <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/286">https://github.com/rust-lang/unsafe-code-guidelines/issues/286</a>)?</p>



<a name="242818115"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242818115" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242818115">(Jun 16 2021 at 00:53)</a>:</h4>
<p>yes.</p>
<p>separately: keep in mind that you can always cast owned to owned regardless of alignment because the casting itself makes the new value aligned. eg: [f32;4] (align 4 array) can always be cast to f32x4 (align 16 simd).</p>



<a name="242818278"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242818278" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242818278">(Jun 16 2021 at 00:55)</a>:</h4>
<p>Indeed.</p>



<a name="242896469"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242896469" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242896469">(Jun 16 2021 at 15:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes/near/242774390">said</a>:</p>
<blockquote>
<p>I suppose that as long as usize has an alignment requirement no <em>more</em> than a pointer, you can always round-trip. It would just mean that not every valid usize is a valid pointer.</p>
</blockquote>
<p>alignment would only affect <em>pointers to</em> usize/pointers, not those values themselbs</p>



<a name="242898473"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242898473" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242898473">(Jun 16 2021 at 15:35)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> When I said "not every valid usize", I meant "usize in memory". If you had a (non-owned) usize aligned on a 2-byte boundary, you couldn't cast it back to a pointer that needs 4-byte alignment.</p>



<a name="242903655"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242903655" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242903655">(Jun 16 2021 at 16:11)</a>:</h4>
<p>you couldnt cast <em>a pointer</em> to the usize</p>



<a name="242903679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242903679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242903679">(Jun 16 2021 at 16:11)</a>:</h4>
<p>you could still easily cast the usize, since that's a by-value operation</p>



<a name="242903757"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242903757" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242903757">(Jun 16 2021 at 16:12)</a>:</h4>
<p>Well, couldn't you read it out of the memory (<code>usize</code> is <code>Copy</code>), then convert?</p>



<a name="242903770"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242903770" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242903770">(Jun 16 2021 at 16:12)</a>:</h4>
<p>so every valid usize is a valid ptr, but not every valid ptr to a usize is a valid ptr to a ptr</p>



<a name="242905991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242905991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242905991">(Jun 16 2021 at 16:29)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> Fair enough, I could have phrased it more precisely.</p>



<a name="242906026"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Relaxing%20Limits%20on%20Pointer%20Sizes/near/242906026" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Relaxing.20Limits.20on.20Pointer.20Sizes.html#242906026">(Jun 16 2021 at 16:29)</a>:</h4>
<p>okay, we mean the same thing then :)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>